Embodiments of the present invention relate generally to methods and systems for supporting definition of services in a Service Oriented Architecture (SOA) and more particularly to supporting definition of services in the SOA using templates for definition of processes, tasks, and/or components and wizards associated to the templates for guiding users in defining values to variables in the templates.
A Service Oriented Architecture (SOA) is a system, i.e., hardware, software, or a combination of hardware and software, providing services or business processes built upon sets of reusable components, e.g., software code, data structures, etc. When constructing or implementing such services, SOA integration projects range from the very simple connection between two edge systems to large-scale business flows between many edge systems that result in collections of service artifacts. To combat technical debt, organizations seek to build reusable components in the hopes that as requirements evolve, services that are already created, can be used in future integration scenarios. This is typically one of the motivating factors to choose a canonical integration style. These large-scale integration projects typically involve multiple teams across an expertise. For example, if a business flow involves multiple different applications, there may be development teams from each application as well as one or more teams driving the overall integration project.
In such projects, the Integration developers are faced with three main challenges. First, the developers should understand the requirements, i.e., what has to be built. A solution architect typically provides a functional design document that describes the requirements and may provide a functional decomposition of the system services that may be required. This functional decomposition typically does not have the technical implementation details, but could be quite granular. Second, the developers should understand the best practices, i.e., how it should be built. Technical debt is created by code that may solve an immediate requirement, but may do so with unintended implications, such as for example, failure to employ an error handling strategy. While the code may do well in a unit test, it might not provide for operational management when put into production. Third, the developers should be completing repetitive tasks to comply with these best practices. For example, following specific naming conventions, creating appropriate scopes, adding error-handling branches etc. are steps that may be documented but can be tedious for the developer to code for each scope. Some of the solutions that the industry has offered are primarily built around documentation of patterns and best practices. However, such solutions still require a thorough understanding of the requirements and best practices by the developers and rely on then to consistently implement the processes accordingly. Hence, there is a need for improved methods and systems for supporting definition of services in a Service Oriented Architecture (SOA).